The comment claims end(data) writes are finished immediately, but the !this.writableEnded guard doesn't actually achieve that. When res.end(data) runs, Node calls _write synchronously before end() sets writableEnded, so inside this _write this.writableEnded === false. I confirmed this empirically:

_write writableEnded=false   <- the end(data) write
_final
after end() writableEnded=true

And end-to-end: a large res.end(bigData) parks its write callback and the end() completion callback does not fire until the body is read (endCallbackFired before read: false). So finish is gated on the first read for a large end(data), exactly what the comment says it avoids.

This is functionally harmless today — the buffering adapter reads the body via arrayBuffer(), which pulls and releases the parked callback, and the response is correctly not marked streamed (because finalizeResponse checks writableEnded, which is true after end() returns). But the stated rationale is inaccurate and could mislead a future maintainer who relies on end(data) writes not parking.

If you actually want end(data) writes to bypass parking, gate on writableEnding (set synchronously at the start of end(), unlike writableEnded) instead of writableEnded:

Otherwise, please reword the comment to drop the "finish them immediately" claim, since parking-then-releasing-on-read is the real behavior.

Minor behavioral note (not blocking): routing streamed API responses through sendWebResponse means compressible content-types now compress in "streaming" flush mode regardless of the 1024-byte COMPRESS_THRESHOLD that the buffered sendCompressed path applies. For a small streamed application/json/text/plain body this adds gzip/br overhead where the buffered path would have skipped it. SSE (text/event-stream) is unaffected since it's not in COMPRESSIBLE_TYPES. Probably fine — a live stream has no known length anyway — but worth a one-line comment so the divergence from the buffered threshold is intentional and documented.

For consistency: the Cloudflare mergeHeaders in server/worker-utils.ts does not copy __vinextStreamedApiResponse (it only strips content-length for the HTML marker). This is not a bug — the Workers path returns new Response(response.body, ...) and streams natively, so it doesn't consume the API marker — but the asymmetry (prod-server + this pipeline propagate it, worker-utils drops it) is a latent trap if a future change makes the Workers adapter branch on the marker. Consider a brief comment in worker-utils.mergeHeaders noting the API marker is intentionally not propagated because Workers streams unconditionally.

Edge case worth a note: a parked write is only released by a consumer pull() or by _destroy. If the returned Response body is never read and never cancelled, the final parked write stays parked, _final never runs, and any handler awaiting pipeline()/drain never settles (its promise is only kept alive via waitUntil). This mirrors real Node (an unconsumed socket also stalls the producer), so it's acceptable — but since this is the one path that can leave a handler promise pending indefinitely, a one-line comment here documenting that release depends on consumption would help future maintainers reason about it.

Minor behavioral divergence (not blocking): routing streamed API responses through sendWebResponse means a compressible content-type (application/json, text/plain) now compresses regardless of the buffered path's 1024-byte COMPRESS_THRESHOLD. A small streamed JSON body will gzip/br where the buffered path would have skipped it. text/event-stream is unaffected (not in COMPRESSIBLE_TYPES). A live stream has no known length so this is defensible, but a one-line comment noting the threshold intentionally doesn't apply to streamed bodies would make the divergence explicit.

Maintainability: __vinextStreamedApiResponse is now a magic string duplicated across pages-api-route.ts, pages-node-compat.ts (typed helpers), this file (inline cast), unified-request-context.ts (inline cast), and prod-server.ts (inline reader). pages-node-compat.ts already exports markVinextStreamedApiResponse / isVinextStreamedApiResponse; consider reusing those helpers (or a shared const for the key) at these copy sites so a future rename can't silently miss one. Mirrors the existing __vinextStreamedHtmlResponse pattern, so this is a pre-existing style choice rather than a new problem.